DISCLAMER: I, ProZaq, take NO RESPONSIBILITY for any damage done to your or anyone else’s computer as a result of following the instructions in this file. I take further NO RESPONSIBILITY for anyone using this file for illegal purposes. If YOU do anything illegal it’s YOUR SHIT! I intend this file for educational purpouses only. I therefore strongly recomend you registering all sharewares, to keep shareware developers alive, and so that we have a chance against the hughe multi-million-dollar software developing companies! If you decide to use the methods described here for illegal things, don’t blame me if you get caught!
--==< Intro >==--
This file is the first part for the complete guide to cracking programs for the Mac. It is planned that when this file is complete it will give a full look at all the ways of cracking programs that I can come up with. There are two references that should be read before reading this article*: “List of Commands” and “Beginner's Guide to Assembly”. The former contains a list of the most common 68K Mac assembly commands and the later is a guide to how assembly language works. Before you go on reading, read “Beginner's Guide to Assembly”, as I asume that anyone reading this already knows assembly! Also, some of you might find this file a bit lenghty and wordy. But remember that I try to describe the methods of cracking thoroughly and in as much detail as possible!
*Weasel's note: “Beginner's Guide to Assembly” was included in HackAddict 5. “List of Commands” is located in “Appendix A: List of Commands” in this issue.
--==< Table of Contents >==--
I. Software you will need
II. How to Use Macsbug
III. Exploiting Dialogs
IV. Using A-traps With Dialogs
V. How to Crack (in theory)
VI. How to Crack (in real life)
VII. End of Part 1
--==< Software you will need >==--
So what will you need to be a cracker? Well you will need MacsBug, and Super ResEdit (ResEdit with a code editor). MacsBug is a debugger. It was created to allow programers to follow their code through and to find errors and incompabilities. Super ResEdit differs from ResEdit in that it allows you to view the “CODE” resource as assembly commands (instead of a bunch of hex numbers). MacsBug is included with this archive. Look for Super ResEdit at www.weasel.org (when it is up) or the HackAddict Hotline Site.
--==< How to Use Macsbug >==--
You install MacsBug simply by throwing it into the system folder, and restarting your machine. You activate it by pressing the “command” and “power-key” (the one towards the top of your keyboard marked with the head of an arrow pointing to the left) buttons. This should have “dropped” you into MacsBug. You will notice that you are in MacBugs ‘cause your desktop is replaced with a with a bunch of numbers on a white background. Well, going from the top left side, under “SP” is the current position of the stack pointer, underneath the position of the SP are the values contained in the SP. Under those numbers is the name of the application that is currently the foremost active. Under that is the status of the Status Register (he he), followed by the info held in the 8 data registers, and the 8 address registers. To the right of the address registers is a horizontal line going across the screen. Under that are about 4 lines of text. The topmost line discribes where in the
application’s code the processor was halted. Under that line are 3 other lines with assembly commands. These are the three commands in line to be executed. To the right of them (in the right bottom corner) are the hexadecimal values of the assembly commands. If the topmost assembly command is a conditional such as BEQ then “Will/ Will not branch” will appear between the command and it’s hex value. Underneath the “Will/ Will not branch” is a hex number. “Will branch” means that the given condition was satisfied and that the program will branch to the address defined by the number underneath the “Will/ Will not branch”. If it says “Will not branch” then the number will appear underneath it too. This means that the program will not branch, but continue on with the next command in line. But would it have branched it would have branched to the memory address represented by the hex number. This is a very important concept and it gets important later on! Above this section is a large empty space. This gets filled up with the results of the commands you give to MacsBug. Your commands get written under the three assembly commands.
What happens when you drop into MacsBug is that your processor stops executing commands, and you can go through a code step by step, command by command, follwoing through exactly what the program does. So how do you do it? Type “t” followed by a return.
This causes the processor to execute the next assembly command in line. The assembly command that was executed appears now in the middle blank section of your screen, and a new assembly command appears under the two old ones.
--==< Basic MacsBug Commands >==--
- t : traces over the next command in line. If it is used on a JSR command it jumps over the the subroutine. (It executes the whole soubroutine, without allowing you to see what happened)
- s : does the same thing as “t” except it “steps into” a subroutine. For example if you are not interested in what happens in an subroutine you should type “t”. This causes the processor to continue untill it reaches a RTS command, and only then give the controll back to you. If you on the other hand want to see what happens in that subroutine, you should type “s” to step into it and follow through the code from there.
- es : this forces the current application to quit (not always).
- rs : restarts your computer (sometimes it doesn work and you have to do it the old fashioned way: apple-control-powerkey)
- rb : reboots your computer (boots up the different external devices at startup). This is slower then the “rb” command
- dm [address] : displays what is in the memory at a given address. For example the command “dm a6” shows you what is held in the address pointed to by address register 6. If you type “dm abcd” it shows you what is held in the memory at location “abcd”.
- db [address] : displays byte from address
- dw [address] : displays word from address
- dl [address] : displays long from address
- il : dissambles the codes. Used if you for example want to see what happens after a branch code.
- atb [a-trap name] : MacsBug activates every time that a-trap is being called.
- atc : clears a-traps
- f address expr ‘string’ : this is the find command. “address” reffers to the starting point of the serch “expr” is how many bytes it should serch and “ ’string” is what you’re looking for! Observe the semi quotation mark before the string! You need to use that!
You can find out more about commands for MacsBug by typing “help”
Super ResEdit is used to a large extent to change the assembly commands and resources in an application. More about it when we need to use it!
--==< Exploiting Dialogs >==--
All right! Let’s get started! The first approach to cracking a program is by exploiting the serial number dialog box. Usually when a software asks you to enter a password or serial number, it puts up a dialog box. By dropping into MacsBug you will be able to follow through the code, see what’s going on, and change the code to fit your needs! The trick with droping into MacsBug is to drop in at the right time. If you don’t then you’ll probably spend hours following through thousands of commands only to find yourself completely lost! So what is “the right time”? The right time is dropping into MacsBug right when it starts the routine which checks the serial number. With other words, dropping in at the series of commands, written by the software author, that deal with the registration. So how do you do this? This is when a-traps become important. You see, MacsBug has this function which allows you to automaticly enter MacsBug. if an a-trap is about to be executed. This is the: “atb [name of a-trap]” function. For example you can type: atb getnewdialog followed by a return, and every time the processor is about to run a “getnewdialog” a-trap you will automaticly be thrown into MacsBug.
Within the Mac OS there are a bunch of a-traps dealing with dialogs. For example a lot of times dialogs use the “ModalDialog” a-trap. So if you want to drop into MacsBug whenever the “modaldialog” trap is called you would drop into MacsBug and give it the following command: “atb modaldialog” (without quotes). Whenever you’re done with a trap, I advise you to give the command “atc” to MacsBug since this turns off the scan for a-traps.
OK I feel lame so I’m gonna give you a list of all the a-traps dealing with dialogs (to the best of my knowledge):
InitDialogs
ErrorSound
GetNewDialog
CloseDialog
DisposeDialog
CouldDialog
FreeDialog
ParamText
ModalDialog
IsDialogEvent
DialogSelect
DrawDialog
UpdateDialog
Alert
StopAlert
NoteAlert
CautionAlert
CouldAlert
FreeAlert
GetDialogItem
SetDialogItem
HideDialogItem
ShowDialogItem
SelDialogItemText
GetDialogItemText
SetDialogItemText
FindDialogItem
NewColorDialog
The truth is that you don’t need to learn all of these, but it might come in handy if you have a list of them all. (The a-traps dealing with alerts refer to alert dialog boxes, ie. ones that only have an OK button on them).
--==< Using A-traps With Dialogs >==--
First I will guide you through the cracking of a program that puts up a registration dialog box and asks you to enter your registration name and registration number.
The principle behind this is as follows: the program puts up the dialog box, then it lets you enter the registration number (reg#) and your registration name, then it takes your registration name and does a bunch of calculations with it, compares the answere to the reg# you entered, and depending on whether the reg# you entered was right or wrong a conditional branch will occur. Remember what conditionals are? Instructions like: BGE, BNE, BEQ (branch if greater or equal, branch if not equal, branch if equal).
So what we want to happen is to drop into MacsBug straight after clicking on the OK button, and then trace through the instructions looking for that conditional which decides wether the reg# we entered was right or wrong. And once we found it we want to change it so that no matter what we type as a reg# it will always say that the number we entered is correct!
The most basic approach to this is through the “ModalDialog” a-trap. Modal dialogs are dialog boxes that are fixed on the screen and only dissapear after you clicked one of the buttons. The only thing you have to know about modal dialog boxes are that information is usually collected from them after the user (cracker) presses the OK button and that the information you typed into the text-fields of the dialog box will be pushed into the memory with the “GetDialogItemText” a-trap!
--==< How to Crack (in theory) >==--
So how would I set out to crack the program in real life? I would start off by picking a unique number (that I can easily recognize) such as 123456789. Then I would enter ANY name as the registration name. Then I would type 12345678 (without the nine) as the reg#. Then I would drop into MacsBug and issue the modaldialog trap command (atb modaldialog). Then I would go back to the application with the “g” command. Then I would type the number nine. This should drop me into MacsBug again. The next command is the trace (“t”) command, which drops me back into the application. Now I would click on the OK button, and find myself in MacsBug. again. And presto, I’m in the right place. After this it is just a matter of steping and tracing through the code tyring to figure out where the conditional branch I want to change is!
“OK, I think I found the conditional I was looking for...What do I do now?” Easy! If the conditional does not branch but you want it to branch, type “pc=address” where address represents the hex number under the place where it says “Will branch” or “Will not branch”. This should have brought you to a whole new place in the code. After giving the “g” command, the “thank you for registering” dialog should appear if you changed the right conditional! However, sometimes the code will branch when you don’t want it to. So if you wanted to jump over the current instruction (since not giving the pc a command is like jumping over a command) you would give MacsBug the command “pc=pc+n”, where n is the length om the assembly instruction. How do you determine n? In MacsBug in the right bottom corner next to the assembly instructions are hexadecimal numbers. These numbers are the equivilents to the assembly commands in hexadecimal form. This way you can determine the commands leangth. Just count how many digits the hex number next to the command is, divide it by two and you have the value of n! So if the number is “AAFE” n would equal 2, and if the number is “AABB 1234” then n would equal 4. Get it?
HINTS:
1. The GetDialogItemText a-trap puts the things you entered in the dialog box in address register one. So by checking the value in address register one (give the command “dm a1”) you can decide where the program is collecting the from the dialog, and where it started to mess around with the registration number.
2. Some people would advise you not to stop for ModalDialog a-traps but to do GetDialogItemText or GetDialogItem a-traps straight away. They would argue that this would bring you further into the code. But I don’t like this approach because the GetDialog commands are usually issued from within subroutines of the main code which means that I have no idea of where in the code I am. But with the ModalDialog I always know that I’m at the command after the dialog a-trap.
3. Stepping thorugh the code can become a bitch! I can storongly suggest that you trace through the code at first! Meaning: jump over subroutines, and check which one brings up the dialog saying that the number you entered is invalid. Chances are that the conditional you’re looking for is in that subroutine. So the next time, step through that subroutine and see what the code does! And if that wasn’t the right subroutine go to the one before it! This WILL save you a lot of time!
3.a) NEVER EVER step into an a-trap! You can reckognize a-traps because they have an “_” sign infront of them.
4. Pay attention to what’s going on in the data and address registers! You are following through the code to understand what the program does! If you try the trial and error way, it will probably take you a hell of a long time! So issue the “dm [addres]” command often!
So this was the theory, now let’s do the real thing!
--==< How to Crack (in real life) >==--
This code is take from a real program. But because of copyright issues I will not name the program I took it from! I will just describe the different steps, and what’s going on! First here is the full code from the ModalDialog trap untill the conditional that I’m looking for:
Wow! Does that firghten you? Well it shouldn’t! If you follow the hints I gave you, you should not even have to spend too much time finding the right conditional. OK here’s a summary of the most important commands from the above exert:
+ 000B0 GetDialogItem
+ 000B8 BNE XXXXXXXX+001AA Will Not Branch
+ 000D2 GetDialogItem
+ 000DC GetDialogItemText
+ 000F2 BlockMove
+ 00108 GetDialogItem
+ 00112 GetDialogItemText
+ 00128 BlockMove
+ 00134 JSR XXXXXX
+ 0013C BEQ XXXXXXX+00142 Will Branch
Ok, so notice the things that I selected to be important! These are the branch commands and the GetDialog a-traps, and the subroutines! An important part of cracking is to reckognize the things you are looking for! And the things you don’t want to spend time on analyzing! Offcourse the first time you’re cracking something you will most likely go through each and every command. But as you get better and better you learn to spot the important ones! In the summary the first GetDialogItem trap and the conditional that follows it are unimportant! I reckognized this by branching onto the address given. Since the program froze on me, that was not the conditional I was looking for! The a-trap at offsett DC is the one that puts the name I put as registration name into address register one and the BlockMove probably stores my name somewhere in the memory. At this point I know that the program is still just collecting the data from the dialog. The next couple of a-traps store the number I entered as a reg# in the memory. At this point I know that now the program has all the data it needs and will soon start checking the reg# I entered. And as I expected soon after the BlockMove there is a subroutine. From common sense I guessed that this subroutine is where the program compares my reg# to the real one. So I trace over it. And at 13C is a conditional. It will branch. So I let it branch and see what happens. I find out that all the things I don’t want to happen, occur. Therefore, I repeat the procedure and come back to this instruction again. But this time I jump over the command. How do I do it? I give MacsBug the command “pc=pc+2” since the hex value of the command is 6704, which is four digits long. This jumps over the command. I issue the command “g”, and voila: the “thank you or registering” dialog appears!
As another example, if the conditional above was not BEQ but BNQ, then the program would not have branched. Let’s say that I wanted it to branch. How do I do it? Easy I just give the command “pc=00D2E79E” since 00D2E79E is the address that appeared under where it says “will not branch”.
--==< End of Part 1 >==--
Well folks, that concludes the first part of this file! Do not think that you’re actually done with cracking the program! But I felt like keeping you in suspense so I will wait ‘till the next issue of HackAddict to let you know how to actally change the code with ResEdit. In Part 2 of The Ultimate Mac Cracking Guide I will also discribe several more ways of cracking programs that can not be cracked with the ModalDialog trap method!
Part 2 will hopefully be published in the next issue of HackAddict. So until then you’ll have plenty of time for experimenting and getting experienced!
